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ABSTRACT 



AESOP, a laboratory-based prototype of a general purpose, on- 
line, visually-oriented information system, is used to investigate ways 
of handling many different types and levels of command and management 
problems spanning organizational levels from the executive suite down 
through the staff and operations analysts to the actual system designers 
and programmers. In particular, it deals with those organizational 
activities that require highly flexible, direct-access capabilities. 

The system is configured for easy use by the inexperienced as 
well as by the sophisticated, and utilizes a variety of user station 
devices to facilitate such flexibility, including a cathode-ray-tube 
display, a lightgun, a typewriter, and associated push-buttons. At 
each station, it is capable of generating, editing, and formatting 
information on-line, as well as building, executing, and debugging 
on-line the analytic and mathematical procedures and algorithms 
of both the users and the system itself, depending upon the organ- 
izational area or level of the user. Although the basic prototype 
system was developed for use in military command and management 
planning and information systems, its philosophy and concepts are 
applicable to industrial and academic organizations. 



in 



AESOP: A General Purpose Approach to Real-Time 

Direct Access Management Information Systems' 



Electronic data processing has made available to organizational manage- 
ment vast resources of timely, accurate, and current data. It has given them 
the support of powerful and rapid computational facilities capable of manipulating 
such data for wide varieties of managerial purposes. However, techniques for 
the managerial use of this electronic capacity for data storage and retrieval, 
or this capacity for the analysis of complex operational models, are only in 
their infancy. The future of computer-aided management is reflected not so 
much in the past utilization of data processing by industrial organizations as it 
is reflected in the military utilization of complex data processing. The United 
States Air Force recognized, at the start of the computer revolution over a 
decade ago, that the full power of central processing and central memory was 
most useful only when that power was delivered in real-time to the desks of 
the users of the system. 

When the power of direct-accessing techniques is realized in industrial 
organizations, we can look forward to the same radical innovation and reorgan- 
ization of organizational life and operational behavior that military command 
experienced earlier. An indication of future information systems that might be 
used for on-line interactive computer management can be obtained if we start 
with our knowledge of the remote station techniques for directly accessing central 
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processors and central memory on a time-shared basis within operating military 

* 
environments, and with capabilities such as those of the AESOP Prototype 

now operating at The MITRE Corporation. Extrapolation from these can yield 

some small glimpses into what will become the new world of organizations. 

It is well not to forget that the vast superiority of telephone communication 
over telegraphic communication in today's day-to-day management activities 
stems not from the fact that one or the other is more conducive to central 
switching, to dialing, to long-lines transmission, or similar central system 
activities, but rather from the fact that the technology of the direct-access 
telephone handset makes it possible for anyone to use the power of the central 
communications system with personal ease and efficiency. In much the same 
sense, the power of tomorrow's time -shared, on-line, direct-access data 
processing will not come when the keyboard of the computer console is placed 
alongside the desk of the manager. It will come when the tools of the on-line 
manager can be placed on his desk, as easy for him to use as his telephone, 
and will bring all of the power of the system to him on his own unique terms. 
If a time-shared direct access system terminates in a multiplicity of teletypes 
or typewriter keyboards, the system then becomes a direct access system for 
programmers, for scientists and engineers, or for clerks or other classes of 
personnel willing and able to communicate with the central processor through 
such devices. 

For senior management, however, the mechanism of communication with 
the processing system must be far more capable of doing what the telephone 
does for him now. It must permit him to interact with the processor without 
having to learn a new language or code, without having to know how to type, 
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without having to wait until the processor noisily hammers out its message to 
him one printed character after another. The typewriters, teletypes, and even 
the vast arrays of pushbuttons that so often accompany current and popular 
impressions of direct access management systems are still of much value, but 
only in the hands of the skilled technicians whose jobs require their special 
capabilities. 

Let us start our look at the AESOP-like management system of the future 

at 
at the desk of the manager of the future. The manager of the future has on his 

desk, in addition to his telephone, a small cathode-ray-tube display, much like 

a small TV set, capable of generating strings of alphanumeric characters, maps, 

charts, graphs, and many of the other normal visual records which managers 

now are accustomed to experiencing by means of reports, documents, letters, 

memoranda, and similar paper products. 

Each display in the AESOP Prototype consists of a page of a file resembling 
a notebook where each page has 30 lines numbered consecutively and there are 
as many pages as there are such sets of 30 lines. Each display has a set of 
columns that are referred to as a section of a file. There are as many sections 
as there are sets of columns. The user T s selection of a specific page and 
section of a file specifies a subset of lines and columns. Customarily, but not 
necessarily, lines identify objects, columns identify properties, as shown in 
Figure 1. 

The user T s notebook contains as many files as are required to hold the 
organizations data base, and also an arbitrary number of files with completely 



Keep in mind, however, that everything discussed below exists today either 
in the military or in the laboratory, and represents nothing more than current 
technology. 




Figure 1. Page 1 Section 1 of a File Dealing with Airfields 



blank pages that serve as the environment within the notebook in which the 
individual user builds his private data base and personal report formats. 

In addition to this relatively standard capability, there is his lightgun. 
The lightgun is a small photoelectric device capable of sensing any of the signals 
appearing on the desk top display whenever it is simply pointed at the location 
of that signal. The signal is then referenced back to the central processor in 
order to indicate the user T s intention or desires. By pointing to critical elements 
on the display, the user has a relatively simple and reliable mechanism for 
communication and interaction with the processor. If the user of the lightgun 
wants the computer to perform some action, he merely points this pointer at 
the appropriate command displayed to him on the display, and the computer 
will operate accordingly. Figure 2a shows a displayed portion of a file — in 
this case page 1 section 1 of a file dealing with Visitors. Figure 2b shows that 
same file with the lightgun firing on one of the side commands, NEXT PAGE. 
Figure 2c shows the same file but now with page 2, section 1 displayed. In the 
same manner, one can communicate to the processor desires for other changes. 
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Figure 2a. Page 1 Section 1 of a File Dealing with Visitors 




Figure 2b. Lightgun Firing on Marginal Command NEXT PAGE 
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Figure 2c. Page 2 Section 1 of The Visitor File 



When the processor has a question, the acceptable set of responses to 
that question may be displayed to the viewer at his desk, and he, in turn, may 
indicate his response by pointing out the correct alternative. If he wishes to 
add messages or data to either a public file or his own private files, he may 
do so through the use of the simple pointer, pointing his way to a display of 
letters or words in sequence and thereby building his message. However, in 
no case should he have to remember the syntax or index necessary for using 
the system. Communicating with a computer via a prescribed language can 
present a training problem when there are many users of the computer. To 
improve this situation in AESOP we have taken the syntax of the primary subset 
of the input language and presented it to the user on the display scope in the 
form of a tree. This tree structure allows an operator to see the legal forms 
of an input message by going down one of the various paths or limbs of the tree. 
A copy of this syntax tree is shown in Figure 3. If the communication is more 
extensive, the manager can always ask his secretary to enter his message by 




Figure 3. The Basic AESOP Communication Tree 

means of the typewriter, which functions not only for her own normal secretarial 
duties, but also as an on-line access mechanism. She can then use this con- 
ventional tool for generating queries, messages, or similar communications 
to the machine and through the machine to other members of the organization. 

The core of the management system of the future will be not so much the 
central processor or central memory, or even a time-shared executive, which 
makes these equally available to all users. The real basis of the system will 
be the unique program of instructions which makes the central processor, the 
central memory, and the organization's store of data and formal quantitative 
models easily available to the manager through the window of his desk top 
display, thus making it possible for him to exert the full power of his intentions 
through the use of his simple lightgun pointer. As AESOP-type management 
systems are developed, managers will learn to converse and interact with the 
processor with ease and naturalness. They will also learn to communicate 
through the processor with other members of the organization. 



Let us now look at the way in which some of the more conventional activities 
of today T s world might be performed in the world of the future. Imagine an 
executive arriving at his office in the morning and sitting down behind his desk. 
On his desk is a small cathode ray tube display and a lightgun that he uses to 
interact with his system. Like all managers, the first thing he does is to call 
up a display showing his appointment schedule for the day. The first display he 
sees is shown in Figure 4a. It gives the schedule for the first working day of 
the month. As indicated in Figure 4b, he turns the page in his schedule to get 
to the schedule for the day in question, January 4. Having examined his calendar, 
he notes that he has a conference for 11:00 a. m. and it is scheduled to carry 
through lunch. He further notes that the discussion is going to deal with a 
specific corporate project. The name of the visitor, Colonel Hertz, strikes a 
familiar bell to the executive but he cannot quite place the exact context of his 
remembrance. He, therefore, asks the system for a retrieval from the organi- 
zations background files on visitors and other very important people. This file 
might be one containing information concerning the individuals organization and 
position, the dates of any past visits, and other significant corporate intelligence 
necessary to facilitate dealing with the visitor. However, rather than accessing 
this file directly by himself, the executive may ask his secretary to do it for 
him. 

The secretary may elect to use her typewriter, as shown in Figure 5a. 
The computer responds to her typed command by displaying the job title, organi- 
zation, visit dates, and purpose of his past visits, as shown in Figure 5b. 
While examining this display the manager may note that a particular project 
leader has been responsible for the previous contacts with this visitor. He then 
requests from that project leader a complete briefing on the status of the project 
in question prior to the arrival of the visitor. In order to do so he simply 
instructs his secretary to send a memo to the project leader with copies to all 
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Figure 4a. Page 1 Section 1 of The January File 




Figure 4b . Page 1 Section 2 of The January File 
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Figure 5a. Typewriter Input Requesting Visitor Information 




Figure 5b. Visitor Index Card 
10 



interested parties telling him that he wants to see him and that he wants to find 
out more about the visitor and about the project in question. The secretary then 
indicates to the processor that she wishes to construct an interoffice memo, as 
illustrated in Figure 6a. 




Figure 6a . Typewriter Input Requesting Interoffice Memo Processing 

The computer responds to her by giving her the blank form shown in 
Figure 6b, which she then proceeds to fill in. When it is finished, as in Figure 
6c, she may then show it to the manager for his approval prior to transmittal. 
To transmit this memo to the project leader is nothing more than transferring 
the message from the file in which the message was constructed to the file that 
constitutes the electronic in-basket of the particular project leader. At the same 
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Figure 6b. Blank Interoffice Memo Form 




Figure 6c. Completed Interoffice Memo 
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time that she does this, the secretary may also enter the project leader's 
appointment with the manager in the manager's electronic appointment book. 

Now let us turn our attention to the project leader 1 s desk. He may be using 
his display to do project scheduling, forecasting or other activities until the 
priority instruction of his supervisor forces the message to his display. Figure 
7a shows his empty electronic in-basket which is soon filled by the priority 
interoffice memo, as in Figure 7b. As a result of reading the message, he 
undertakes to prepare the review requested by his manager by calling up various 
status displays and ending up with the budgetary report shown in Figure 8a. 
Once again we see that the normal record and paper products of management 
life appear on this display in a form not very different from the way that it 
probably would be typed on paper today. In fact, one might well view a display 
data base as many vast notebooks, handbooks, and files of records available 
whenever needed and to whomever the organization allows to see the information. 
In fact, many of today 1 s files that are now maintained on paper are also main- 
tained in the computer. 

To continue with our story, the project leader, having reviewed the budget 
figures, will use his lightgun to copy certain portions of the records into what 
can be called an electronic vu-graph. The copy message superimposed on the 
budget display is shown in Figure 8b. After indicating what he wishes to copy 
into the vu-graph file (Figure 8c) he switches to the vu-graph file and indicates 
where he wants the information to go, as shown in Figure 8d. The information 
is then transferred as shown in Figure 8e. This vu-graph file can then be called 
up later when he wishes to brief his manager. In glancing over this particular 
vu-graph, the project leader recognizes that line 19 has no data on it and so he 
erases it as shown in Figures 9a, 9b, 9c, and 9d. 
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Figure 7a. AESOP Version of Executive In-Basket 




Figure 7b. AESOP In-Basket With Interoffice Memo 
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Figure 8a. Budget Report 




Figure 8b. Skeleton Message to Allow On-Line Data Manipulation Via Lightgun 
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Figure 8c. Skeleton Message With Partially Completed Parameter Insertion 
for Copy Message 




Figure 8d. Completed Message for Copy Instruction 
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Figure 8e. Result of Copy Instruction 

In much the same way any number of vu-graphs can be prepared, edited 
and re-formatted on-line, until they are exactly as he may want them. 

This has been a very brief introduction into the future world of the manager, 
in which electronic information displays have started to replace paper as the 
primary vehicle for organizational life. Of course, this is not really all there 
is to the management system of the future. As we will see, much of the power 
of such a system lies in its ability to give a manager direct access to forecasting 
devices, scheduling tools, and other quantitative methods of modern management 
which, at the present time, must and can be accessed only through specialists 
and the intervention of operations analysts and programmers. 

An AESOP-like on-line management system must operate for the benefit 
of many members of an organization. There must be capabilities suitable for 
use by higher level executives, and at the same time, there must be capabilities 
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Figure 9a. Lightgun Firing on Marginal Command, ERASE 




Figure 9b. Skeleton Message to Allow On-Line Data Manipulation 
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Figure 9c. Completed Message Specifying Line and Columns To Be Erased 




Figure 9d. Result of Erase Instruction 
19 



suitable for use by others, equally valuable, to support the forward movement 
of the system design engineers and system programmers who have responsibility 
for development, maintenance, and improvement of the system capability. 

For the higher level executives, the exercising of algorithms built by his 
staff of operations analysts can be in the mode of parameter insertion that allows 
him to call up specific routines requiring only the input of key values. To 
illustrate this management technique, we have chosen a military example where 
the problem is to determine the availability of aircraft at up to three bases for 
assignment to a specific target area. Figure 10a shows the work file in which 
input data has been loaded for use by the routine. The second section of this 
same file is reserved for the answer as shown in Figure 10b. A list of routines 
can be called up and from them we will select one called STATUS1 as shown in 
Figure 10c. STATUS1 tells us how many aircraft are available at what squadrons, 
from what bases, what the distance is to the target area, and what the one-way 
flying time is. The parameters for this routine are the line numbers from 
which the input data is to be taken and the line numbers on which the output data 
is to go. Once we have filled in the parameters for this routine to operate as 
shown in Figure lOd, we lightgun the word EVALUATE and examine the data 
that this routine has generated. The results are given in Figure lOe. 

However, this simple kind of parameter insertion is not enough. The 
management system must also be able to support the work of the operations 
analysts and functional area experts whose analyses and quantitative methods 
constitute much of the power and capability of the system itself. These analyses 
and quantitative methods require an algorithm-building or construction capability. 
This too, is part of the present AESOP prototype system. 

To illustrate how we make use of this capability, we will now set up a 
simple multiplication. To do this, we call up the same display shown in Figure 10c. 
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Figure 10a. Page 1 Section 1 of Work File Loaded With Data To Be Used By Routine 
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Figure 10c. Algorithm Communication 
Tree Showing Available Commands, 
Elements, and Routines 



Figure lOd. Inserted Parameters To Be 
Used With STATUS1 Routine 
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Figure 1 Oe . Result of STATUS1 
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We then lightgun the ARITH operators in the elements branch. This action causes 
the display of all of the arithmetic operators available to the user, as shown in 
Figure 11a. We then lightgun the MULTIPLY symbol in the arithmetic operators, 
causing it to appear in the upper right of the display indicated in Figure lib. 




(a) 




(b) 

Figure 1 1 . Steps in The On-Line Construction of a Primitive Procedure 
to Multiply 30 by 30. 
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Lightgunning the word EXP in the workspace causes two syntactic limbs to 
appear under the multiply sign which tell us that we must multiply at least two 
numeric expressions one by the other, Figure lie. To obtain some numbers to 
use in the multiplication, we lightgun the word NUMBERS. The resulting display, 
Figure lid, allows us to compose any number we desire by lightgunning the 
numerals successively from left to right. The constructed number appears 
under the heading on the right called RESULT. 



(c) 





Figure 1 1 . Cont. 



(d) 
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The number 30 is constructed by lightgunning the numbers 3 and in suc- 
cession. Lightgunning FINISH returns us to our familiar display with the number 
we constructed in the upper right of the display, in this case 30, as shown in 
Figure lie. We now have composed a complete command, REPLACE THIRTY, 
and we will lightgun EXPRESSION in the workspace twice. Figure llf shows the 
operation or algorithm we have constructed, "multiply 30 by 30. ,f Having con- 
structed the simple multiplication, we lightgun the word EVALUATE, causing 
the answer to be printed out on the console typewriter. Figure llg. 




(e) 



(0 



(X 30 30) 
VALUF .. 900 



(9) 



Figure 1 1 . Concl 'd , 
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Having shown the principles of use we will now briefly illustrate a logical 
operation. From the set of logical operators obtained by lightgunning the word 
LOGIC, we lightgun the word FOR and obtain the display shown in Figure 12a. 
Once again let us call your attention to the fact that a syntax specification is 
included. In all cases, wherever an ambiguity could arise or whenever the next 
action requires a specialized knowledge of the syntax, the system provides this 
information to the user. In this particular situation, when FOR appears in the 
workspace it tells us that for some variable from some number to some number 
we will be executing some expression. From the variable list we pick C, and 
we will place it in the workspace. We next go to our numbers and construct 
the number 1. We will place this under the FROM NUMBER in the workspace. 
In the same way, we construct the rest of the expression until it is in the form 
we wish as shown in Figure 12b. 

The expression now reads, "For C as it goes from one to ten type C, a 
spacer of four dots and C to the tenth power. " We next lightgun the word 
EVALUATE and again the answer will appear on the console typewriter. 

With the two capabilities just illustrated, that is, parameter insertion 
and analytical method construction, we have a good deal of flexibility, although 
not enough for real-time management systems. 

Essentially, the flexibility of an on-line processing system reflects not 
only its ability to perform in support of many people at many levels in organi- 
zation, but also to change on-line, in response to new and changing demands 
upon it at many different levels and places in the total organization or environ- 
ment. 

When AESOP, or for that matter, any on-line management system, operates 
in an organizational context, the users of that system have to be able to do more 
than develop, store, and execute their own job-oriented programs. They must 

26 




(a) 




(b) 



Figure 12. Steps in The Construction of a More Complex Algorithm 
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also share the common data base, the common data retrieval and updating 
routines, and the common on-line processing procedures designed to use this 
data base. At the same time, each of these users must have some ability to 
modify the system 1 s performance to meet the changing needs of his job, without 
violating the performance of the system in support of other organizational 
members whose jobs do not warrant alteration of system capabilities. 

The full flexibility also implies an ability of the system users to change, 
on-line, the performance of the system, to meet their own changing needs or 
wishes, while other members of the system are simultaneously using the system 
in its original form. This implies a design strategy by which the system enables 
its users to access all of its current capabilities while other users are pro- 
gramming and debugging these changes and modifications. In effect, the system 
should permit multiple copies of itself to operate simultaneously, thereby making 
it possible for system supervisors and organizational managers to review 
alternative forms of system operation in order to agree upon the acceptability 
of the proposed modifications and extensions. 

To aid the on-line programmer faced with debugging problems or with a 
requirement from higher organizational levels to change given routines, the 
AESOP prototype has made a provision for this capability. To illustrate this 
capability we will change the STATUS1 routine utilized earlier, so that we get 
information on only the closest airfield. To do this we call up a routine called 
DEBUG. Figure 13a shows the routine code. Note that it is in the same familiar 
tree structure seen before. On the leftmost limb of the display are some com- 
mands to assist us in looking at the routine. When we wish to look through the 
routine, we can lightgun any node and this node is immediately brought over to 
the second limb of the tree. Figure 13b shows the statement that we wish to 
change. Lightgunning the word OAK takes what was in the secondmost limb of 
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the debug tree into the algorithm format explained earlier, as shown in Figure 
13c. This is now available for modification and change. To modify this pro- 
gram we are going to delete the entire expression in the workspace and replace 
it with the expression A = 1. The equals tells us that some variable must be 
set equal to some expression. The expression we are going to use will be simply 
the number 1, since the variable A controls the number of airfields that are 
checked. Having modified the expression in the same way we built the earlier 
algorithms, Figure 13d, we lightgun the command RETURN and the modified 
expression is placed back in the second limb of the display, Figure 13e. Light- 
gunning RESTORE brings back the beginning of the routine. Lightgunning DEFTR 
redefines the routine to include the modifications. The routine can be re-exercised, 
this time asking that its answer be placed on line 10 rather than line 6. Figure 
13f shows the output of both operations. 

These three capabilities, parameter insertion, algorithm building, and 
debugging, together with the capabilities indicated earlier, constitute the AESOP 
Prototype system. It has something for everyone in the organizational hierarchy. 
It is this last "something for everyone 1 ' that we believe characterizes the manage- 
ment information system of the future. 
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(d) 



Figure 13. Steps in The Modification of an Interpreted System or User Procedure 
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Figure 1 3. Concl 'd . 
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